home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1993…ch: Other People's Memory / ADC Developer CD (1993-03) (''Other People's Memory'')_iso / Dev.CD Mar 93.iso / Development Platforms / Apple II / Essentials / Technical.Notes / PDOS / TN.PDOS.030 < prev   
Encoding:
Text File  |  1992-07-15  |  6.6 KB  |  131 lines  |  [TEXT/GEOL]
  1. Apple II
  2. Technical Notes
  3. _____________________________________________________________________________
  4.                                                   Developer Technical Support
  5. ProDOS 8
  6. #30: Sparse Station
  7.  
  8. Written by: Matt Deatherage                                          May 1992
  9.  
  10. This Technical Note discusses issues when using sparse files under ProDOS 8.
  11. _____________________________________________________________________________
  12.  
  13.  
  14. SPARSE INFORMATION AVAILABLE
  15.  
  16. The concept of sparse files is introduced in the ProDOS 8 Technical Reference
  17. Manual in sometimes confusing language.  The concept behind sparse files is
  18. pretty simple.  If you didn't think it could be explained in two paragraphs,
  19. have a seat and learn something.
  20.  
  21. The ProDOS file system keeps track of where files reside on disk through a
  22. series of "index blocks."  All index blocks are disk blocks that contain lists
  23. of block numbers.  They may be organized in several ways (seedling, sapling or
  24. tree), depending on how big the file is--one 512-byte block can hold 256
  25. two-byte block numbers.  If a file is one block long, it has no index blocks
  26. and is a seedling file.  If a non-sparse file is between two and 256 blocks
  27. long, it has one index block and is a sapling file.  If a non-sparse file is
  28. longer than 256 blocks, it's a tree file and has a "master index block" that
  29. points to other index blocks.  This is more than enough to store any ProDOS
  30. file--one master index block pointing to 256 other index blocks, each of which
  31. points to 256 data blocks on disk would be a 32 MB file--twice the limit of 16
  32. MB imposed by ProDOS's 3-byte storage for file lengths.
  33.  
  34. What happens if you don't need to use all of those blocks?  For example, if
  35. you need to store data at file offset $0000 and at file offset $20000, does
  36. ProDOS make you waste 256 disk blocks you're not going to use?  Fortunately,
  37. the answer is "no."  ProDOS lets you skip any data block you're not using by
  38. recording a pointer to data block $0000 instead of to a regular block on the
  39. disk.  When ProDOS sees a block pointer of $0000 in an index block, it knows
  40. not to read block zero (which contains boot code) but instead to pretend that
  41. it read a block of zeroes from the disk.  This lets you save lots of space on
  42. disk--a file created this way is a sparse file.  (See?  Two paragraphs.)
  43.  
  44. Under ProDOS 8, you can create a sparse file by using the SET_EOF MLI command
  45. to extend the file's current end-of-file position, and then using SET_MARK to
  46. move the mark to the new end-of-file position.  If you grow a file by
  47. increasing the EOF but not actually writing data, ProDOS 8 makes the blocks
  48. you skip sparse.  Under GS/OS, the ProDOS FST automatically converts long
  49. stretches of zeroes to sparse blocks, making sparse files even more prevalent.
  50.  
  51. DEALING WITH SPARSITY
  52.  
  53. Unfortunately, ProDOS 8 does not automatically make sparse files when you
  54. write large sections of zeroes.  That means if you read a sparse file and
  55. write it back out, you "expand" it and it's no longer sparse.  The file could
  56. balloon to hundreds of times its previous disk space, which is not a good
  57. thing.
  58.  
  59. So how do you recognize a sparse file?  You can notice that the length of the
  60. file has to be pretty close to 512 bytes multiplied by the number of blocks
  61. allocated to data in the file.  For example, take a file that's $4068 bytes
  62. long.  $4068 bytes takes 33 512-byte blocks--32 blocks is $4000 bytes, plus
  63. one more block for the last $68 bytes.  This is between 2 and 256 blocks, so
  64. there's one more block allocated for the index block.  If this file is not
  65. sparse, it uses 34 blocks on disk.  If it uses any less than 34 blocks in
  66. reality, it's sparse.
  67.  
  68. This calculation gets a little tricker for tree files--if the file has more
  69. than 256 data blocks, add one master index block plus one index block for each
  70. 256 data blocks or portion thereof.  To give another example, a file that's
  71. $68D3F bytes long takes 839 ($347) data blocks.   This file has five
  72. additional blocks allocated to it--one master index block and four index
  73. blocks.  The first three index blocks are full (256 Y 3 = 768) and the fourth
  74. contains the remaining 71 data blocks.  If this file takes less than 844
  75. blocks on disk, it's sparse.
  76.  
  77.  
  78. TOO COMPLICATED?
  79.  
  80. For all except very speedy utilities to copy files, yes.  If you just need an
  81. easy way to deal with sparse files that's not so speed-critical, read on.
  82.  
  83. All you have to do to preserve (or create) sparsity in normal file copying
  84. operations is scan the data you've read from disk before you write it back.
  85. Suppose your file copying buffer is 10K large.  Read 10K of data from your
  86. source file, then divide the buffer into 512-byte chunks and scan the data
  87. looking for zeroes.  If you find a non-zero byte, write the entire 512-byte
  88. chunk of data to the target file and proceed to the next 512-byte chunk.  If
  89. you don't find any non-zero bytes in a 512-byte chunk, just set the mark ahead
  90. 512 bytes and don't issue a WRITE call.  This is basically how GS/OS's ProDOS
  91. FST automatically sparses files, and it can work for you too.
  92.  
  93.  
  94. IS IT THAT EASY?
  95.  
  96. Well, no.  There's an important exception--AppleShare.
  97.  
  98. Most AppleShare servers (including all of Apple's) don't support sparse
  99. files--all the logical blocks you use have to be physically allocated on the
  100. server's hard disk.  The following BASIC.SYSTEM command:
  101.  
  102.      BSAVE SPARSE.FILE,A$300,L$1,B$FFFFFF
  103.  
  104. creates a 16 MB sparse file with one byte of logical data in it.  This file
  105. only takes 5 blocks on a ProDOS disk (one master index block, two index blocks
  106. and two data blocks--it takes two data blocks because ProDOS 8 always
  107. allocates the very first block of a file when you create it, even if you don't
  108. use the first 512 bytes), but it takes 16 MB of disk space on a server.
  109.  
  110. That's not all--for speed reasons, AppleShare does not fill the extra,
  111. normally-sparsed blocks with zeroes.  If you issued the above command to an
  112. AppleShare server under ProDOS 8 and then tried to read the first few bytes of
  113. the resulting file, they would be garbage--but not zeroes.
  114. ProDOS 8 Technical Note #21 gives information on identifying AppleShare server
  115. volumes--if you're dealing with one, do not use normal sparse file creation
  116. techniques.  Just write the 512 bytes of zeroes instead of advancing the mark.
  117. It doesn't take any more disk space and it achieves the results you want.
  118.  
  119.  
  120. ONE MORE THING
  121.  
  122. In versions of ProDOS 8 up to 1.9, setting the end-of-file position past $200
  123. on a seedling file created a sparse file that confused ProDOS 8 if you ever
  124. used SET_EOF on it again.  This is fixed in version 2.0.1 and later.
  125.  
  126.  
  127. Further Reference
  128. _____________________________________________________________________________
  129.  
  130.    o   ProDOS 8 Technical Reference Manual
  131.